【レポート】「JBUG (札幌#3) プロジェクト管理について、もっと学ぼう！」に行ってきた

佐々木一洋

2019.03.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、最近の札幌は寒さも緩み春が近づいているのが感じられます。

さて今回は、2/22 に開催されたJBUG (札幌#3) プロジェクト管理について、もっと学ぼうに参加してきたのでレポートします。

第1回の模様はまっちさんによるレポートブログ、「JBUG 札幌#1に行ってきました！」で紹介されています

ピカピカの会場とザンギ

会場はフュージョン株式会社さんのイベントスペースでした。フュージョンさんは昨年移転されたばかりで会場はとてもおしゃれできれいでした。私は開始10分ほど前についたのですがその時にはすでに参加者がぎっしりと着席されてました。

そして今回もヌーラボさんから布袋のザンギ（とても大きな鳥の唐揚げ）とピザ、ドリンクが提供されていました。私はこのザンギが大好きなのでとても美味しくいただきました。

「Backlogの歩き方」by 金田彩花さん (フュージョン株式会社)

トップバッターの金田さんは、前職でBacklogをかなり活用されていたようで、現職のフュージョンでもっとBacklogを活用してもらおうと活動されているそうです。

発表ではご自身の体験からBacklogの使い方のポイントをいくつか紹介されていました。その中で私が印象に残ったのは下記の２点です。

情勢のキャッチアップ

Backlogはプロジェクトごとにメール通知の設定が行えます。

「プロジェクトごとの性質や使い方によって通知設定を変えることで必要な情報だけを通知するのが大事」ということでした。

私自身はあまりメールをチェックする習慣がないのでこの設定は意識していなかったのですが、金田さんが「Wikiで管理しているマニュアルが更新されたら通知を受け取って内容を確認するようにしている」という使い方を聞いて、自分としては特別なアクションは必要ないが目を通しておきたい情報（例: サーバの構成情報や運用手順など）を通知できることがわかりました。（メールあまり見ない問題、についてはメールは見なくてもIFTTなどでSlackに連携して通知すればカジュアルに更新情報が見られるなと思います）

課題に作業の進捗や経緯、結末を記録する

「付き合いが長い顧客から過去の経緯などを尋ねられた時に、Backlogに記録が残っていて、自分が担当する前のことでも返信することができた」という経験を踏まえて次のことが重要とお話しされていました。

対応履歴を整理して残す
誰が・何を・なぜ・どうした・誰の判断で
主語を忘れずに
結末をかく
対応完了したら課題の概要に「結論」を書く
経緯はコメントに記録する
主語を忘れずに！！！！！(これはとても強調されていました）

障害や問い合わせに対して対応している間は手を動かすのに精一杯で、記録を取るのを忘れがちですが、未来の自分や後任のメンバーのために記録を残しておくことで、お客様への対応の品質や速度も変わってくるのだなと、改めて記録の重要性を認識しました。

「課題の粒度で迷わないために」 by 長広竜一さん (株式会社フォーク)

長広さんは課題の粒度を統一するために、WBSを使って作業の洗い出しと構造化をした上で、課題を作成する方法を紹介されていました。

作業の洗い出しと構造化

具体的には次の３ステップで作業を洗い出し、構造化するそうです。

Step1：最終目標の設定
Step2：作業の洗い出し（細分化しすぎると、関係性がわからないのでざっくり）
Step3：構造化（されているかのチェック）

１つの議論で完了するものを１作業と考えてBacklogの課題を作成するのがコツで、複数の議論が出てきた場合は課題を分割するされているそうです。１課題で複数の議論が起こると課題の終了条件がわかりにくくなることがあるので、これは１つの基準として良いかもしれないと思いました。

構造化のステップでは、同じ粒度の作業のアウトプットが一つ上の作業に紐づいているかを確認していくそうです。この確認のステップがあると作業のアウトプットや作業間の依存関係を改めて考えることになり、網羅性や精度もよくなりそうだと思いました。

Backlogへのマッピング

上記の方法で構造化した作業をBacklogでは下記のようにマッピングしていくそうです。レベル１〜３は洗い出して階層化した作業の各レベルを表しています。

マッピング例 1

レベル１ プロジェクト
レベル２ マイルストーン
レベル３ 課題

マッピング例 2

短期間で終わり繰り返し同じような流れの作業があるキャンペーンなどの場合はこちらを使っているそうです。

レベル１ マイルストーン
レベル２ 課題
レベル３ スプレッドシート

ここまで具体的だとメンバー間で課題の粒度が違ってしまうこともないし、手順が決まっていると課題の登録もスムーズにできそうだなと思います。

「現場エンジニアのプロジェクト進行を考える」 by 吉江健斗 (クラスメソッド株式会社)

最後の発表は弊社AWS事業部でAWSの設計、構築を行っている吉江が、自身がこれまで使ってきたプロジェクトマネジメントツールの変遷と、現在の業務にPMBOKの各プロセスをどのように当てはめているか紹介しました。

私はPMBOKについてはほぼ知識がないのですが、AWSインフラの提案、構築を行う弊社の業務であっても適用できるほどPMBOKの範囲は幅広いことがわかりました。

LT チケット運用の工夫 by 半田惇志さん(株式会社パンセ)

プロジェクトで発生する情報は同期的/非同期的、ストック型/フロー型に分類でき、それぞれの特性に合わせてBacklogの機能を使っていくのが大事、というお話でした。

コメントの議論で決まったこと（フロー型）を課題の概要欄に書くことでストック型情報に変えられるので、情報を見直すことができるようにしている、ということでした。このやり方は金田さんの発表でもお話しされていたので良い習慣なのだと思います。

発表の詳細はこちらの記事で紹介されています。

「現場エンジニアのプロジェクト進行を考える」というお題で登壇してきました。 #JBUG

感想

金曜の夜でしたが多くの方が参加されていて、発表の質疑応答も活発だったのでプロジェクト管理やBacklogは注目度が高いのだなと感じました。プロジェクト管理はこのやり方が一番いいというものを決めるのが難しいことなので、このように色々な人の話を聞いて考えたり、普段の業務を振り返るのは大事だと思いました。